본방 환경, 개발 환경을 나눌 때 ALB는 어떻게 나누는 것이 좋을까?

본방 환경, 개발 환경을 나눌 때 ALB는 어떻게 나누는 것이 좋을까?

본방 환경, 개발 환경을 나눌 때 ALB는 어떻게 나누는 것이 좋은지 정리해 봤습니다.
Clock Icon2023.10.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번에는 본방 환경, 개발 환경을 나눌 때 ALB는 어떻게 나누는 것이 좋은지 정리해 봤습니다.

환경 별로 ALB 나누기

먼저 첫 번째로 본방 환경과 개발 환경별로 ALB를 나누는 것입니다.

타겟 그룹도 로드 밸런서와 동일하게 본방 환경, 개발 환경별로 나눈 상태입니다.

  • http://test-dev-alb-xxxxxx.ap-northeast-3.elb.amazonaws.com/
  • http://test-prd-alb-xxxxxx.ap-northeast-3.elb.amazonaws.com/

각각 ALB DNS 이름을 통해 접속합니다.

본방 환경으로 문제 없이 접속 가능합니다.

개발 환경으로도 문제 없이 접속 가능합니다.

상황에 따라 다르겠지만 따로 리스너 규칙을 설정할 필요 없이 본방 환경과 개발 환경을 나누어 접속할 수 있습니다.

이렇게 환경별로 ALB를 나누면 다음과 같은 이점이 존재합니다.

  • 각 환경마다 ALB를 나눔으로써 각 환경에 발생하는 문제를 분산시킬 수 있다.
    • 예를 들어 개발 환경에서 발생한 문제를 본방 환경에 영향을 미치지 않도록 할 수 있다.
  • 각 환경 별로 ALB를 나눔으로써 트래픽과 리소스 사용률을 분리하고 관리할 수 있다.
  • 각 환경에 맞는 액세스 제어 정책을 적용할 수 있다.
    • 본방 환경, 개발 환경을 나누어 보안 등급을 나누어 설정할 수 있다.
      • 특히 본방 환경의 경우 더 엄격하게 적용할 수 있다.
  • 독립적인 확장이 가능하다.
    • 각 환경 별로 ALB를 독립적으로 확장할 수 있으며, 각 환경에 따라 성능을 조절할 수 있다.

이렇게 환경 별로 ALB를 나눈다면 상기와 같은 이점을 가질 수 있습니다.

어떻게 보면 환경 별로 ALB를 나누는 것이 가장 일반적인 구성이라고 할 수 있겠습니다.

여기서 서브 도메인을 취득해서 접속하고 싶은 경우 아래 블로그를 참고해 주세요.

 

하나의 ALB로 구성

다음은 하나의 ALB로 본방 환경과 개발 환경을 제어하는 방법입니다.

포트 기반 라우팅

리스너 추가해서 80번 포트에는 본방 환경으로, 81번 포트에는 개발 환경으로 접속할 수 있도록 포트를 나눕니다.

구성도로 확인해 보면, 본방 환경으로 접속하고 싶은 경우에는 80번 포트로 접속하며, 개발 환경으로 접속하고 싶은 경우에는 81번 포트로 접속합니다.

타겟 그룹내에서의 포트 번호는 변경할 필요 없이 그대로 80번 포트를 사용합니다.

  • http://test-alb-xxxxxx.ap-northeast-3.elb.amazonaws.com
  • http://test-alb-xxxxxx.ap-northeast-3.elb.amazonaws.com:80

다음 URL로 접속을 시도하면 문제 없이 본방 환경을 접속합니다.

  • http://test-alb-xxxxxx.ap-northeast-3.elb.amazonaws.com:81

81번 포트로 접속을 시도하면 문제 없이 개발 환경으로 접속할 수 있습니다.

※ ALB의 보안 그룹에 81번 포트를 설정해야합니다.

경로 기반 라우팅

이번에는 포트가 아닌 URL 패스를 나누어서 접속해 보도록 하겠습니다.

구성은 다음과 같습니다.

본방 환경으로 접속하는 경우 기존 80번 포트로 그대로 접속을 시도합니다.

타겟 그룹 내부에서의 설정도 따로 변경할 필요없습니다.

특정 패스를 통해 접속을 시도하는 개발 환경의 경우 리스너 규칙과 타겟 그룹 및 EC2 내부에서의 설정이 필요합니다.

[root@ip-xx-x-xxx-xxx html]# mkdir test-dev
[root@ip-xx-x-xxx-xxx html]# cd test-dev
[root@ip-xx-x-xxx-xxx test-dev]#
[root@ip-xx-x-xxx-xxx test-dev]#
[root@ip-xx-x-xxx-xxx test-dev]# vi index.html

개발 환경의 대상 EC2 인스턴스에서 /var/www/html/ 경로가 아닌 /var/www/html/test-dev/ 라는 경로에 index.html 파일을 생성합니다.

이어서 개발 환경의 타겟 그룹을 수정합니다.

여기서 헬스체크 경로를 /test-dev/ 경로로 설정합니다.

이어서 ALB의 리스너 규칙을 추가합니다.

규칙 조건 유형은 경로로 설정하고, 해당 경로를 /test-dev/* 로 설정합니다.

마지막으로 /test-dev/* 경로로 접속한다면, 개발 환경의 타겟 그룹으로 라우팅 하도록 설정합니다.

  • http://test-alb-xxxxxx.ap-northeast-3.elb.amazonaws.com/test-dev/

마지막으로 /test-dev/ 경로로 접속을 시도해 보면, 개발 환경으로 접속이 가능한 것을 확인할 수 있습니다.

마지막으로

실제로 본방 환경과 개발 환경에서 사용하는 웹 서버(EC2 인스턴스)를 하나의 ALB로 관리하면 어떨까? 라는 생각으로 블로그를 작성해 봤습니다.

결과적으로는 어느쪽이든 가능한 방법이라고 생각하지만, 환경별로 ALB를 나누는 것이 더 메리트가 있다고 생각합니다.

포트, 경로 기반 라우팅의 경우에는 환경 별로 나누는 상황이 아닌, 같은 EC2 인스턴스 혹은 같은 환경에 속한 EC2 인스턴스에서 여러 경로로 나누고 싶은 경우에 유용하지 않나 생각합니다.

본 블로그 게시글을 읽고 궁금한 사항이 있으신 분들은 jaewookkim533@yahoo.com로 보내주시면 감사하겠습니다.

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.